-
Notifications
You must be signed in to change notification settings - Fork 30
Reformat pull request template #211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
andrewcoughtrie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having a hard time telling what has been changed in this. There is a lot of unneeded line length changes, the original had an 80 character max width keeping it inline with all other files in the repo and the guidelines; this allows easier viewing in editors without the need to deal with wrapping or scrolling.
I also have some comments on the changes I can see are different in the questions,
| - [ ] My code follows the project's [style guidelines](https://metoffice.github.io/lfric_core/how_to_contribute/index.html#how-to-contribute-index) | ||
| - [ ] Comments have been included that aid understanding and enhance the readability of the code | ||
| - [ ] My changes generate no new warnings | ||
| - [ ] All automated checks in the CI pipeline have completed successfully |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the point of this question is, the ticket won't merge if they haven't passed so there should be no need to ask this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what the point of this question is, the ticket won't merge if they haven't passed so there should be no need to ask this.
Currently, certain actions may fail or not run but still proceed to review. I believed this was the place to clarify that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I can agree with that, I do think these questions need reviewing regularly to avoid becoming too onerous.
Co-authored-by: Andrew Coughtrie <24609575+andrewcoughtrie@users.noreply.github.com>
Nothing significant, except that the standard 80-character line length restriction has been removed. It's frustrating that GitHub still breaks lines when rendering on pull requests, just like in the template. |
andrewcoughtrie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having a hard time telling what has been changed in this. There is a lot of unneeded line length changes, the original had an 80 character max width keeping it inline with all other files in the repo and the guidelines; this allows easier viewing in editors without the need to deal with wrapping or scrolling.
Nothing significant, except that the standard 80-character line length restriction has been removed. It's frustrating that GitHub still breaks lines when rendering on pull requests, just like in the template.
There are reasons we have an 80 character limit, diff tools don't work as well when there are long lines, small changes can result in diffs that are much harder to read. Text editors wrapping can make short cut keys much less effective is there are long lines that are wrapped. Also reading really long lines is harder if the span the whole screen (which they are doing while I review this change). I could see an argument for increasing the width to say 120 characters but I don't think removing the limitation entirely is a good idea.
| - [ ] My code follows the project's [style guidelines](https://metoffice.github.io/lfric_core/how_to_contribute/index.html#how-to-contribute-index) | ||
| - [ ] Comments have been included that aid understanding and enhance the readability of the code | ||
| - [ ] My changes generate no new warnings | ||
| - [ ] All automated checks in the CI pipeline have completed successfully |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I can agree with that, I do think these questions need reviewing regularly to avoid becoming too onerous.
andrewcoughtrie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I can see what you mean about the rendering of line breaks in the PR. It does seem to only happen that it force the code line breaks in the PR, if you view the file as just MD it does the wrapping correctly.
However as the primary purpose of this is in the PR template removing the line wrapping seems like a reasonable thing to do. I wouldn't suggest we do this for any other MD files though leaving this the exception.
|
Yep. The line-limit is still 80-char for markdown everywhere. |
PR Summary
Sci/Tech Reviewer: NA
Code Reviewer: @andrewcoughtrie
The PR body was adding literal line breaks as specified in the template, which was not ideal. I have removed the 80-character markdown formatting restriction from the template to improve how it displays on GitHub PRs.
Code Quality Checklist
(Some checks are automatically carried out via the CI pipeline)
style guidelines
readability of the code
Testing
NA
using this branch
acceptable (e.g. kgo changes)
tests, unit tests, etc.)
and have been allocated to an appropriate testing group (i.e. the
developer tests are for jobs which use a small amount of compute resource
and complete in a matter of minutes)
Security Considerations
Performance Impact
NA
performance measurements have been conducted
AI Assistance and Attribution
NA
of Generative AI tool name (e.g., Met Office Github Copilot Enterprise,
Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the
Simulation Systems AI policy
(including attribution labels)
Code Review